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I. REAL PARTY IN INTEREST 

United States Patent Application Serial No. 10/064,080 (the "Application") is owned by 
Crossroads Systems Inc., a corporation organized and existing under and by virtue of the laws 
of the State of Texas, and having its principal place of business at 11000 N. Mo-Pac Expy. 
Austin, TX 78759 and Hewlett Packard Company, a Delaware Corporation, having its principle 
place of business at 3000 Hanover Street Palo Alto, California. 
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II. RELATED APPEALS AND INTERFERENCES 

Appellants believe that there are no related appeals or interferences. 
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III. STATUS OF CLAIMS 

Claims 1-22 of the Application were filed in the original filing of the Application on June 
10, 2002. Claims 1, 11, 18 and 22 were amended in Applicant's Reply to Office Action dated 
April 15, 2005. Claims 20 and 21 were withdrawn in Applicant's Reply to Restriction 
Requirement filed November 16, 2005. Claims 1-19 and 22 stand finally rejected and Claims 
20-21 are withdrawn from consideration. Claims 1-19 and 22,. which are rejected under 35 
U.S.C. §1 02(e), are the subject of this appeal. A copy of Claims 1-19 and 22 is included in the 
Appendix hereto. 
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IV. STATUS OF AMENDMENTS 

No amendments were filed subsequent to the final rejection. The first amendment to the 
application, filed on April 15, 2002 amended Claims 1, 1 1, 18 and 22. The Reply to Restriction 
Requirement filed November 16, 2005 withdrew Claims 20-21 . The Appendix hereto reflects 
the current state of the claims as amended by the April 15, 2005 Reply to Office Action and the 
status of claims 20-21 as withdrawn. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

Independent Claims 1,11 and 22 are subject to the present appeal. 
Claim 1 recites: 

A method of using a router to cache inquiry data corresponding to a 
target device in a network having a plurality of client devices, the 
method comprising: 

storing inquiry data corresponding to a target device in a cache 
memory; 

receiving a request for the inquiry data corresponding to the target 
device; 

reading the inquiry data from the cache memory; and 
providing the inquiry data corresponding to the target device in 
response to the request. 

The recited invention, according to Claim 1, performs the steps of "storing inquiry data 
corresponding to a target device", "receiving a request for the inquiry data", "reading the inquiry 
data from the cache memory" and "providing the inquiry data corresponding to the target 
device." 

Claim 1 1 recites: 

A device comprising: 

a router configured to route data between one or more hosts 

and one or more target devices; and 
a cache memory coupled to the router; 
wherein the router is configured to store inquiry data 

received from the one or more target devices and to 

provide at least a portion of the stored inquiry data in 

response to a request for inquiry data corresponding to 

one of the target devices that is busy. 



Thus, according to Claim 1 1 , the router stores inquiry data from one or more target devices and 
provides inquiry data in response to a request for inquiry data corresponding to a target device 
that is busy. 

Claim 22 recites: 

A computer readable medium, wherein the computer 
readable medium contains one or more instructions 
which are configured to cause a computer to perform the 
method of using a router to cache inquiry data 
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corresponding to a target device in a network having a 

plurality of client devices, the method comprising: 
storing inquiry data corresponding to a target device in a 

cache memory; 
receiving a request for the inquiry data corresponding to the 

target device; 
reading the inquiry data from the cache memory; and 
providing the inquiry data corresponding to the target device 

in response to the request. 

Claim 22, thus includes instructions for "storing inquiry data corresponding to a target device", 
"receiving a request for the inquiry data", "reading the inquiry data from the cache memory" and 
"providing the inquiry data corresponding to the target device." 

Claims 1,11 and 22 provide systems and methods for caching inquiry data for a target 
device so that requests for the inquiry data (i.e., inquiry commands) "to the target device can be 
serviced when the target device is busy processing previously serviced commands." See 
Application, 1J0009. Inquiry commands are commands "which request data that is, for the most 
part, static." See Application 1J0005. The inquiry data requested by the inquiry command is 
data that "typically relates to the device itself, rather than data which [it] is designed to store or 
generate" and is generally static data such "as serial number, manufacturer, configuration, 
version number, or similar data" but "may also include data that changes relatively infrequently." 
See Application 1J0005. 

Embodiments of the present invention include a method implemented on a router to 
respond to inquiry commands. As shown in FIGRUE 2, a router routes commands, including 
inquiry commands, from clients to target devices. See Application 1J0023. The router is coupled 
to a cache" which is "designed to store inquiry data" associated with a target device. See 
Application 1J0024. When a router receives an inquiry command destined for a target device, 
the router can forward the inquiry command to the target device. See Application fl0029. "After 
the target device processes that command, it provides data responsive to the command. See 
Application ^0029. The router does two things with the data it receives back from the target 
device, "it stores the data in it cache; and it forwards the data to the host device that originally 
requested it." See Application ^[0029. Thus, the inquiry data corresponding to the target device 
is stored in the cache in addition to being forwarded to the requesting host. 



Attorney Docket No. CROSS 1490 
Ser. No. 10/064,080 



Appellant's Brief 



When the router receives a subsequent request for the inquiry data 
corresponding to the target device, the router can "checks the cache to determine whether or 
not it has the data." See Application 1J0030. "If the data is stored in the cache, the data is read 
fro the cache and then forwarded to the host device in response to the inquiry command." See 
Application 1J0030. In other words, the router can provide a response to the inquiry command 
using inquiry data already stored at the router. Consequently, if the target device is busy 
processing another command, the inquiry command can be serviced from the cache of the 
router. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1-10 and 22 are unpatentable under 35 U.S.C. §1 02(e) over U.S. Patent 
No. 6,725,272 B1 ("Susai"). More specifically, the Examiner incorrectly asserts that the Susai 
reference discloses the limitations of the invention in question. 

Even more specifically, the Examiner incorrectly asserts that, as per claim 1, Susai 
teaches method of using a router to cache inquiry data corresponding to a target device in a 
network having a plurality of client devices comprising: 

storing inquiry data corresponding to a target device in a cache memory (Fig 2, column 
4, lines 16-33; column 5, lines 66-column 6, lines 17); 

receiving a request for the inquiry data corresponding to the target device(Fig 2, column 
4, lines 16-33; column 5, lines 66-column 6, lines 17, Susai discloses storing inquiry data 
corresponding to a target device) ; 

reading the inquiry data from the cache memory (Fig 2, column 4, lines 16-33; column 5, 
lines 66-column 6, lines 17, Susai discloses receiving a request for the inquiry data); and 

providing the inquiry data corresponding to the target device in response to the request 
(Fig 2, column 4, lines 16-33; column 5, lines 66-column 6, lines 17, Susai disclose reading 
inquiry data from a cache). 

Additionally, the Examiner incorrectly asserts that, as per Claim 11, Susai teaches a 
device comprising: 

a router configured to route data between one or more hosts and one or more target 
devices (Fig. 2, Column 4, lines 16-49, Susai discloses a router); and 

a cache memory coupled to the router (Fig. 2, Column 4, lines 16-33, Susai discloses 
memory); 

wherein the router is configured to store inquiry data received from the one or more 
target devices and to provide at least a portion of the stored inquiry data in response to a 
request for inquiry data corresponding to one of the target devices that is busy (Column 4, lines 
16-33; Column 5, lines 66 - Column 6, line 41, Susai disclose router storing inquiry data). 

Finally, with respect to Claim 22, the Examiner incorrectly asserts that Susai teaches a 
computer readable medium, which are configured to cause a computer to perform a method 
comprising: 



Attorney Docket No. CROSS 1490 
Ser. No. 10/064,080 



Appellant's Brief 



storing inquiry data corresponding to a target device in a cache memory (Fig 2, column 
4, lines 16-33; column 5, lines 66-column 6, lines 17, Susai discloses storing inquiry data 
corresponding to target devices); 

receiving a request for the inquiry data corresponding to the target device(Fig 2, column 
4, lines 16-33; column 5, lines 66-column 6, lines 17, Susai discloses storing inquiry data 
corresponding to a target device) ; 

reading the inquiry data from the cache memory (Fig 2, column 4, lines 16-33; column 5, 
lines 66-column 6, lines 17, Susai discloses receiving a request for the inquiry data); and 

providing the inquiry data corresponding to the target device in response to the request 
(Fig 2, column 4, lines 16-33; column 5, lines 66-column 6, lines 17, Susai disclose reading 
inquiry data from a cache). 
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VII. ARGUMENT 
REJECTIONS UNDER 35 U.S.C. §1 02(e) OVER SUSAI 

1 Introduction 

The Examiner rejected Claims 1, 11 and 22 under 35 U.S.C. 102(e) as being anticipated 
by the Susai reference. Appellant respectfully disagrees with the Examiner. 

To anticipate a claim, a single reference (or event) must expressly or inherently disclose 
each and every limitation of a claim. See Moba B.V. v. Diamond Automation, Inc., 325 F.3d 
1306, 1233 (Fed. Cir. 2003) and Hybritech Inc. v. Monoclonal Antibodies, Inc., 802 F.3d 1367, 
1379 (Fed. Cir. 1986). The entire prior art reference may be reviewed for anticipatory material, 
not just the claims of the reference (if the reference is a patent or printed patent publication). 

The prior art must sufficiently describe the claimed invention to have placed the public in 
possession of it. See Minnesota Mining & Mfg. Co. v. Johnson & Johnson Orthopedics, Inc., 
976 F.2d 1559, 1572 (Fed. Cir. 1992). However, the prior art does not have to use the same 
terminology. In re Bond, 910 F.2d 831, 832-33 (Fed. Cir. 1990). 

To constitute an anticipatory reference, the prior art must contain an enabling disclosure. 
See Chester v. Miller, 906 F.2d 1574, 1576 n.2 (Fed. Cir. 1990) and Helifix Ltd. v. Blok-Lok, 
Ltd., 208 F.3d 1339 (Fed. Cir. 2000). A reference contains an enabling disclosure if a person of 
ordinary skill could have combined the description of the invention in the prior art reference with 
his own knowledge of the art to have placed himself, and thereby the public, in possession of 
the invention. See In re Donohue, 766 F.2d 531 , 533 (Fed. Cir. 1985) and In re Paulsen, 30 
F.3d 1475, 1479 (Fed. Cir. 1994). 

The test for anticipation is symmetrical to the test for infringement. See Lewmar Marine 
Inc. v. Barient f Inc., 827 F.2d 744, 747 (Fed. Cir. 1987), cert, denied, 484 U.S. 1007 (1988) 
(stating "that which would literally infringe [a claim] if later in time anticipates if earlier than the 
date of invention."). 
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The Appellant respectfully submits that the Susai reference does not disclose or teach 
each and every claim limitation of Claims 1,11 and 22 and therefore does not anticipate Claims 

1, 11 and 22. 

2. Background 

In the Background of the Invention section of the Application, the Appellant describes the 
manner in which requests for inquiry data were previously handled. Conventionally, inquiry 
commands are treated the same as other commands received by a target device and are 
serviced when the device becomes available. See Application, 1J0007. This can cause 
problems if a previous command takes too long to process because the inquiry command will 
not be processed until the previously received command is serviced. See Application, 1J0007. If 
the inquiry command is blocked long enough, the inquiry command will time out. See 
Application, 1J0007. As a result, the host issuing the inquiry command may assume that the 
target device is no longer operational or longer connected to the network even if the target 
device is connected and operational. See Application, 1^0006-0007. 

Susai is related to handling of requests to a requested server that is busy. Specifically, 
Susai is related to Internet client server applications, and more specifically, to guaranteeing 
network client-server response time while providing a way of putting the client on-hold when the 
response time temporarily prohibits access to a requested server. See Susai, col. 1, lines 17- 
21. 

In Susai, a network includes a plurality of clients, a plurality of servers, an interface unit 
202 and one or more "on-hold" servers 204. See Susai, col. 4, lines 38. In the preferred 
embodiment, the interface unit is an intelligent network interface card with a CPU inside a 
server. See Susai, col. 4, lines 17-19. Preferably all Internet requests from clients to servers go 
through interface unit 202. See Susai, col. 4, lines 40-42. When interface unit 202 receives an 
Internet request directed to a server, interface unit 202 determines the identity of the requested 
server. See Susai, col. 5, lines 1 1-12. Once interface unit 202 determines the identity of the 
server to which a request is directed, interface unit 202 opens a connection to that server if a 
free connection is not already open. See Susai, col. 5, lines 16-21. Interface unit 202 then 
determines the response time of the requested server based on the actual past response times. 
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See Susai, col. 5, lines 22-49. The estimated current response time is then compared to a 
threshold value. See Susai, col. 5, lines 50-51. If the requested server cannot provide an 
acceptable response time, then interface unit 202 puts the requesting client "on-hold". See 
Susai, col. 5, lines 59-61. 

When a client is put on-hold, interface unit 202 determines the approximate waiting time 
for the client. See Susai, col. 6, lines 44-46. Depending on the approximate waiting time, 
interface unit 202 determines the on-hold request to send to on-hold sever 204 as different 
content is designed to be available depending on the waiting time. See Susai col. 6, lines 61- 
66. Interface unit 202 translates the initial on-hold request and passes it to on-hold server 204. 
See Susai, col. 7, lines 25-27. After request processing, interface unit 202 receives a response 
from the on-hold server and passes the response to the client. See Susai, col. 7, lines 27-31. 
While the client is on-hold, various types of information can be provided to the client, including 
music, sports, news and so forth. See Susai, col. 6, lines 1-4. 

While a client is on-hold, interface unit 202 can continue to determine the current 
response time of a requested server. See Susai, col. 8, lines 12-17. If the current estimate 
response time is still above the threshold response time, the client remains on-hold. See Susai, 
col. 8, lines 20-24. If the current estimated response time is below the threshold, interface unit 
202 determines if the client is the next to be serviced by the requested server, based for 
example on FIFO or LIFO queuing. See Susai, col. 8, lines 26-35. If the client is the next to be 
serviced by the requested server, interface unit 202 determines if the client is done with on-hold 
server 204. See Susai, col. 8, lines 36-37. If the user is finished with on-hold server 204 (as 
indicated by the user or determined by the system), the user is taken off-hold and clients 
request is passed to the requested server. See Susai, col. 8, lines 37-49. 

Thus, in Susai, a client issues a request to a requested server. Interface unit 202 
receives the request and compares the requested server's expected response time a threshold. 
If the requested server's expected response time is too long, interface unit 202 issues an on- 
hold request to on-hold server 204 and forwards the response from on-hold server 204 to the 
client. When the requested server's expected response time drops below the threshold and the 
client can be taken off of on-hold, interface unit 202 sends the request from the client to the 
requested server and forwards the response from the requested server to the client. 
Consequently, when interface unit 202 receives a request from a client it either i) forwards an 
on-hold request to on-hold server 204 for on-hold content and forwards the response from the 
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on-hold server to the requesting client; or ii) forwards the request to the requested server and 
forwards the response from the requested server to the client. 

3. Improvements Over the Prior Art 

The invention of the Application improves upon the conventional prior art of handling 
inquiry commands by caching inquiry data. Once the inquiry data corresponding to a target 
device is stored (e.g M at a router), the device caching the inquiry data can respond to inquiry 
commands to that target device (i.e., requests for the inquiry data corresponding to that target 
device) if the target device is busy, offline, broken, missing or cannot respond for some other 
reason. See Application 1J0007. Consequently, inquiry commands requesting inquiry data 
corresponding to a particular target device can be serviced even if the target device itself cannot 
respond to the inquiry command. 

4. Rejections Under 35 U.S.C. §102(e) 

The Examiner rejected all of the claims in the Application under 35 U.S.C. §1 02(e) as 
being anticipated by U.S. Patent No. 6,725,272. To anticipate a claim, a reference must teach 
every element of the claim. Although the terminology can be different, the elements must be 
arranged in the manner required by the claim M.P.E.P. 2131. The Appellant respectfully 
submits that Susai does not teach every element of the Claims 1-19 and 22. 

4.1 Rejections Under 35 U.S.C. 102(e) of Claims 1-10 and 22 

4.1.1 Examiner's / Appellant's Positions Regarding Anticipation 

The Examiner asserts that Susai shows each and every limitation of Claims 1 and 22. 
The Examiner incorrectly cites various portions of Susai as showing storing inquiry data 
corresponding to a target device in a cache memory"; "receiving a request for the inquiry data 
corresponding to the target device"; "reading the inquiry data from the cache memory"; and 
"providing the inquiry data corresponding to the target device in response to the request." The 
Appellant respectfully submits that Susai fails to disclose any of these limitations. 
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4.1.2 Not All Claim Elements Are Shown: 

Independent Claim 1 of the Application recites: 

A method of using a router to cache inquiry data corresponding to a 
target device in a network having a plurality of client devices, the 
method comprising: 

storing inquiry data corresponding to a target device in a cache 
memory; 

receiving a request for the inquiry data corresponding to the target 
device; 

reading the inquiry data from the cache memory; and 
providing the inquiry data corresponding to the target device in 
response to the request. 

Independent Claim 22 of the Application recites: 

A computer readable medium, wherein the computer 

readable medium contains one or more instructions 

which are configured to cause a computer to perform the 

method of using a router to cache inquiry data 

corresponding to a target device in a network having a 

plurality of client devices, the method comprising: 
storing inquiry data corresponding to a target device in a 

cache memory; 
receiving a request for the inquiry data corresponding to the 

target device; 
reading the inquiry data from the cache memory; and 
providing the inquiry data corresponding to the target device 

in response to the request. 

Thus, both independent Claims 1 and 22 include the features of "storing inquiry data 
corresponding to a target device in a cache memory"; "receiving a request for the inquiry data 
corresponding to the target device"; "reading the inquiry data from the cache memory"; and 
"providing the inquiry data corresponding to the target device in response to the request." Thus, 
according to both Independent Claim 1 and Claim 22, when a request for inquiry data 
corresponding to a target device is received, the request can be serviced from cache memory of 
a router rather than forwarded to the target device. 

4.1.2.1 Susai Does not Teach Inquiry Data 

As described in 1J0005 of the Application, inquiry data relates to the target device itself 
and may include, for example, serial number, manufacturer, configuration, version number or 
similar data corresponding to the target device. A request for inquiry data, or an inquiry 
command, is thus not simply a request for any data stored on a target device, but is a request 
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for data about the target device itself. See Application 1J0005-0006. As one example, in a 
system that utilizes the SCSI protocol such as the example described in 1J0022 of the 
Application, the SCSI standard provides an inquiry command for the SCSI protocol to which 
particular data corresponding to the target device is returned. In particular, as defined by the 
SCSI standard, SCSI INQUIRY DATA can include: vendor identification field, product 
identification field, product revision level field and other data corresponding to the target device. 

Requests for inquiry data may be submitted for various reasons. For example, when a 
new host is booted, it checks to see which other devices are connected to the network. See 
Application 1J0006. Hosts may also periodically use inquiry commands to obtain information 
regarding the availability of devices on the network. See Application TJ0006. If a device 
responds to the request, the host will receive the responsive inquiry data and will be aware that 
the device is available. See Application 1J0006. If the device does not respond, the host may 
assume either that the device is no longer connected to the network or that the device is no 
longer functioning properly. See Application 1J0006. 

In summary, inquiry data corresponding to the target device pertains to the target device 
itself. Requests for inquiry data corresponding to a target device issued to the target device, 
particularly a sequential access target device, may time out if received following a time 
consuming command, thus causing the command issuing host to erroneously believe that the 
target device no longer exits on a network. 

Susai does not appear to address inquiry data and requests for inquiry data. The 
requests processed by the interface unit in Susai appear to be HTTP requests or other TCP/IP 
requests for information stored on a target device but not information about the target device 
itself (e.g., serial number, manufacturer and other such inquiry data). See Susai, col. 9, lines 5- 
14. The only concrete example of a request for data is a GET request for a file at path name 
/sales/forecast.html, which is simply a request for data on a target device not a request for data 
about the target device. See Susai, col. 10, lines 27-42. Nothing in Susai teaches inquiry data 
corresponding to a target device or a request for inquiry data corresponding to a target device. 
For this reason alone, Susai does not disclose "storing inquiry data corresponding to the target 
device"; "receiving a request for inquiry data corresponding to the target device"; "reading the 
inquiry data" or "providing inquiry data corresponding to the target device." Therefore, Susai 
cannot anticipate Claims 1 and 22. 
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4.1.2.2 Susai Does not Teach Responding to A Request by Providing 
the Requested Data from A Cache Memory 

Claims 1 and 22 recite "storing inquiry data corresponding to a target device in a cache 
memory"; "receiving a request for the inquiry data corresponding to the target device"; "reading 
the inquiry data from the cache memory"; and "providing the inquiry data corresponding to the 
target device in response to the request." Thus, the router of Claims 1 and 22 stores inquiry 
data corresponding to a target device in cache memory and uses the inquiry data already stored 
in cache memory to respond to requests for inquiry data. 

As described in the Application, for example, a router routes data between the hosts and 
target devices. See Application 1J0022. When the router receives inquiry data from a target 
device, the router performs both the functions of i) routing the data to the requesting host and ii) 
storing the inquiry data in the cache (i.e., for responding to later requests for inquiry data from 
the same target device). See Application 1J0029 (stating "the router does two things with the 
data: it stores the data in its cache; and it forwards the data to the host device that originally 
requested it"). Because the router of Claims 1 and 22 stores inquiry data in a cache memory, it 
can respond to requests for the inquiry data. When the router receives a subsequent command 
from the host device and the target device is busy, the router will provide a response if possible. 
"In order to provide a response, the router must have the data necessary to service the request 
stored in its cache. It therefore, checks to the cache to determine whether or not it has the data. 
If the data is stored in the cache, the data is read from the cache and then forwarded to the host 
device in response to the inquiry command." See Application 1J0030. This allows the router to 
respond for the target device when the target device is busy. See Application fl0026. 

In the final office action, the Examiner cited FIGRE 2, column 4, lines 16-33 and column 
5, lines 66 through column 6, lines 17 as showing each of the claim limitations. FIGURE 2 of 
Susai simply shows a network diagram. See Susai, FIGURE 2. Column 4, lines 16-33 of Susai 
states: 

FIG. 2 is a network context diagram for an interface unit 
202 and an on-hold server(s) 204 according to a preferred 
embodiment of the present invention. In a preferred 
embodiment, interface unit 202 is an intelligent network 
interface card with a CPU inside a server. Interface unit 
202 can also be intelligent box sitting outside the server, 
in which case it can serve more than one server. Interface 
unit 202 can also be a load balancer, bandwidth manager 
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firewall, proxy-cache, router, switch, computer system, or 
any other network device that is located between a client 
and server. In theory, on-hold server 204 represents the 
world's largest web site. Users (via clients) are temporarily 
redirected to on-hold server 204 when their requested 
server is too busy to accommodate their page requests. 
On-hold server(s) 204 may be physically located within 
interface unit 202, may be an independent server directly 
connected to interface unit 202 or may be an independent 
server located anywhere on the Internet. 

This portion of Susai simply discusses redirecting a request to an on-hold server, but 
does not teach or suggest "storing inquiry data corresponding to a target device", "receiving a 
request for the inquiry data", "reading the inquiry data from the cache memory" or "providing the 
inquiry data corresponding to the target device." 

The other cited portion of Susai-Column 5, line 66-col. 6, line 17-states: 

Interface unit 202 puts the client on-hold, as shown in 
step 310, and as more fully described with respect to FIG. 
4A and FIG. 4B, below. While the client is on-hold there is 
no limit to the types of information that can be provided to 
the client by the present invention, including music, 
sports, news and so forth. It is important to note that there 
may be one or more on-hold servers 204 utilized by the 
present invention that the client may be directed to. In the 
case of having multiple on-hold servers 204 to choose 
from, the present invention may use various factors in 
determining which on-hold server 204 to direct the client 
to. These factors may include such things as client IP 
address, type of request and on-hold server 204 load. 
Hence, on-hold service may be a distributed service. An 
on-hold portal by definition should relinquish control to the 
request controller. This control switching is initiated by 
client-side intelligence (Java Applets/Scripts), interface 
memory (where the interface remembers the held 
requests) and on-hold server 204 initiated re-direction. 
The re-direction can be at the IP level or at the HTTP 
level. 

Again, this portion of Susai simply discusses redirecting a request to an on-hold sever 
that serves content while a request is on-hold. 

FIGURE 7 and the accompanying discussion provide an example of how a request is 
handled according to the system of Susai. According to Susai: 

First, interface unit 202 opens a connection with client 700 
using network address 1 provided by client 700, as shown 
by flow 702. Once the connection is opened, interface unit 
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202 receives a GET request from client 700 specifying a 
path name of/sales/forecast.html, as shown by flow line 
704. Assume at this point, interface unit 202 determines 
that the GET request is for requested server 701 and that 
the estimated response time for requested server 701 is 
such that client 700 must be put on-hold 

Interface unit 202 maps the appropriate GET on-hold 

request to on-hold server 204 Interface unit 202 

forwards the GET on-hold request to on-hold server 204, 
as shown by flow line 706. On-hold server 204 responds 
with the requested web page, as shown by flow line 708. 
Interface unit 202 forwards the web page to client 700. as 
shown bv flow line 709 . 

See Susai, col. 10, lines 18-38 (emphasis added). As the emphasized portions 
demonstrate, when a client is put "on-hold," requests for data are not responded to with a 
cached version of the requested data but are responded to with arbitrary content from an on- 
hold server. In this case, the on-hold server responds to the request while the interface unit of 
Susai simply acts as a router to forward the content from the on-hold server to the requesting 
client. There is no disclosure that the interface stores the response from the on-hold server in a 
cache memory or that the interface unit responds to a subsequent request using data read from 
the cache memory of the interface unit 

Susai goes on to describe how the request is handled when the client is taken off of on- 
hold, stating: 

Once interface unit 202 determines that client 700 is 
ready to be taken off on-hold (as described in FIG. 5), the 
GET reouest from client 700 specifying a path name of 
/sales/forecast.html is sent or replayed to requested 
server 701 . as shown by flow line 710. But, prior to this, 
client 700 sends a WAKE command to interface unit 202 
and interface unit 202 responses back to client 700, as 
shown by flow line 718 and 719, respectively. Next, 
requested server 701 responds with the requested web 
pace, as shown bvflow line 712. Interface unit 202 
forwards the web page to client 700, as shown bv flow 
line 714 . Finally, interface unit 202 closes the connection 
with client 700 using network address 1 , as shown by flow 
line 716. 



See Susai, coL 10, lines 49-61 (emphasis added). According to this portion of Susai, when a 
client is taken off of on-hold, the request from that client is forwarded to the requested server 
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and the reply from the requested server is forwarded to the client. Again, in this case, the 
interface unit simply routes a response to the appropriate client from the requested server but 
does not store the response in a cache memory or read already stored data from the cache 
memory to respond to the request. 

While the interface unit of Susai may provide some undisclosed memory functionality to 
route data, this functionality is part of the routing data back and forth between the clients and 
servers. There is no disclosure or teaching of "storing inquiry data corresponding to a target 
device in a cache memory"; "receiving a request for the inquiry data corresponding to the target 
device"; "reading the inquiry data from the cache memory"; and "providing the inquiry data 
corresponding to the target device in response to the request". 

4.1.2.3 Summary 

Susai does not address "inquiry data corresponding to a target device" and therefore 
cannot teach the recitations of " storing inquiry data corresponding to a target device in a cache 
memory"; "receiving a reguest for the inguiry data corresponding to the target device "; "reading 
the inguirv data from the cache memory"; and " providing the inquiry data corresponding to the 
target device in response to the request." 

Moreover, even if the data in Susai is erroneously interpreted to be inquiry data, Susai 
does not teach "storing inquiry data corresponding to a target device in a cache" and, in 
response to a request for the inquiry data "reading the inquiry data from the cache memory" and 
"providing the inquiry data corresponding to the target device in response to the request." 
Instead, Susai teaches that requests to a requested server are either responded to by an on- 
hold server (i.e., with data that was not requested in the request) or is responded to by the 
requested server (i.e., by the server that is the target of the request). There is no disclosure or 
teaching that the interface unit stores response data in a cache memory and reads response 
data from a cache memory to provide a response to a request for that data. 

Consequently, Susai does not anticipate Claims 1 or 22. By virtue of their dependency 
on Claim 1 , Susai also does not anticipate Claims 2-10 for the foregoing reasons. 
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4.2 Rejections Under 35 U.S.C. 102(e) of Claims 10-19 

4.2.1 Examiner's / Appellant's Positions Regarding Anticipation 

The Examiner asserts that Susai shows each limitation of Claim 1 1 . The Appellant 
respectfully submits that Susai fails to teach "[a] router [configured] to store inquiry data 
received form the one or more target devices and to provide at least a portion of the stored 
inquiry data in response to a request for inquiry data corresponding to one of the target devices. 

4.2.2 Not All Claim Elements Are Shown 

Independent Claim 11 of the Application recites: 
a device comprising: 

a router configured to route data between one or more hosts and one 

or more target devices; and 
a cache memory coupled to the router; 

wherein the router is configured to store inquiry data received from 
the one or more target devices and to provide at least a portion 
of the stored inquiry data in response to a request for inquiry 
data corresponding to one of the target devices that is busy. 

According to Claim 1 1 , a router routes data between one or more hosts and one or more 
target devices. The router also stores inquiry data received from the target devices. When the 
router receives a request for inquiry data corresponding to a target device that is busy, the 
router can return a portion of the stored inquiry data in response to the request. 

4.2.2.1 Susai Does Not Teach Inquiry Data 

As discussed above, Susai does not appear to address inquiry data. The requests in 
Susai appear to be HTTP requests or other TCP/IP requests for information stored on a target 
device but not information about the target device itself (e.g., serial number, manufacturer and 
other such inquiry data). See Susai, col. 9, lines 5-14. The only concrete example of a request 
for data is a GET request for a file at path name /sales/forecast.html, which is simply a request 
for data on a target device not data about the target device. See Susai, col. 10, lines 27-42. 
Nothing in Susai teaches inquiry data corresponding to a target device or a request for inquiry 
data corresponding to a target device. For this reason alone, Susai cannot disclose a router 
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"configured to store inquiry data" or to "provide at least a portion of the stored inquiry data." 
Consequently, Susai cannot anticipate Claim 11. 

4.2.2.2 Susai Does Not Teach a Router Configured to Respond to A 
Request for Inquiry Data Corresponding to One of the Target Devices That is Busy Using 
Stored Inquiry Data 

Claim 1 1 recites a router configured to route data between one or more hosts and one or 
more target devices and " to store inquiry data received from the one or more target devices and 
to provide at least a portion of the stored inquiry data in response to a request for inquiry data 
corresponding to one of the target devices that is busy ." Thus, according to Claim 11, the 
device that routes data between hosts and target devices also stores inquiry data received from 
the target devices. When the router receives a request for inquiry data corresponding to a 
target device that is busy, the router can respond with the stored inquiry data. 

In rejecting Claim 11, the Examiner cited FIGURE 2 and column 4, lines 16-33 as 
showing "a router configured to route data between one or more hosts and one or more target 
devices." Column 4, lines 16-33 of Susai, reproduced above, describe that an interface unit 202 
can be any number of network devices and FIGRUE 2 of Susai shows interface unit 202 located 
between clients and servers. Thus, it appears that the Examiner is considering the interface 
unit to be the router. 

The Examiner went on to cite col. 4, lines 16-33 and col. 5, line 66 - col. 6, line 41 of 
Susai as disclosing that "the router is configured to store inquiry data received from the one or 
more target devices and to provide at least a portion of the stored inquiry data in response to a 
request for inquiry data to one of the target devices." Column 4, lines 16-33 simply describe 
that "users are temporarily redirected to on-hold server 204 when their requested server is too 
busy." See Susai, column 4, lines 26-27. Again, according to Susai, a user request is simply 
put on on-hold. There is nothing in Susai that teaches or suggests a router that stores inquiry 
data corresponds to a target device and responds to requests for inquiry data using the stored 
inquiry data. 

Susai, at, column 5, line 66 through column 6, line 41 also does not teach a router 
"configured to store inquiry data received from the one or more target devices and to provide at 
least a portion of the stored inquiry data in response to a request for inquiry data corresponding 
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to one of the target devices that is busy" and, indeed, teaches something quit different. This 
section of Susai teaches that an interface unit puts the client on-hold. See Susai, column 5, 
lines 66-67. While the client is on-hold, information can be provided to the client such as music, 
sports, news and so forth. See Susai column 6, lines 1-4. This information is provided by the 
on-hold server, not from data stored at the interface unit. See Susai, col. 10, lines 34-38, stating 
"on-hold server 204 responds with the requested web page . . . interface unit 202 forwards the 
web page to the client . . . When a client request is ready to be taken off on-hold, the 
interface unit of Susai "translates the client request and passes it to the requested server." See 
Susai, col. 6, lines 25-27. Thus, if a requested server is busy, the interface unit of Susai puts 
the request on-hold, forwards an on-hold request to the on-hold server, and forwards a 
response from the on-hold server to the client The interface unit does not respond with inquiry 
data previously stored by the interface unit. 

Thus, even when the interface unit of Susai is considered to be a router, Susai does not 
disclose or teach all the limitations of Claim 1 1 . Particularly, when the interface unit of Susai 
receives a request directed to a requested server that is busy, Susai generates an on-hold 
request to an on-hold server and routes the response of the on-hold server to the requesting 
client. The interface unit does not respond with already stored inquiry data from the one or 
more target devices. 

4.2.2.3 Summary 

Susai does not address "inquiry data corresponding to a target device" and therefore 
cannot teach the recitations of a router that is "configured to store inquiry data received from the 
one or more target devices and to provide at least a portion of the stored inquiry data in 
response to a request for inquiry data corresponding to one of the target devices that is busy." 

Furthermore, when a requested server is busy, the interface unit of Susai simply routes 
responses from the on-hold server to the requesting client. The interface unit of Susai does not 
"provide at least a portion of the stored inquiry data in response to a request for inquiry data 
corresponding to one of the target devices that is busy." 

Consequently, Susai does not anticipate Claim 1 1 . By virtue of their dependency on 
Claim 1 1 , Susai also does not anticipate Claims 12-19 for the foregoing reasons. 
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5. Conclusion 

As explained above, the Appellant believes that Susai does not show each limitation of 
claims 1,11 and 22, and that the corresponding rejection of claims 1-19 and 22 should properly 
be withdrawn. The Appellant therefore respectfully requests that all of the rejections be 
withdrawn and that all the pending claims 1-19 and 22 be allowed. 
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A check in the amount of $500.00 is included with this filing. A request for a one month 
extension of time and check in the amount of one hundred and twenty ($120) were previously 
filed on June 19, 2006. While Applicant believes no further fees are due and owing, if Applicant 
is in error, the Commissioner is hereby authorized to deduct the appropriate amount from 
Deposit Account No. 50-3183 of Sprinkle IP Law Group. 




Respectfully Submitted, 
Sprinkle l£J.aw Group 



Date: July 19,2005 



1301 W. 25 th Street, Suite 408 
Austin, TX 78705 
Tel. (512)637-9220 
Fax. (512) 371-9088 
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VIII. CLAIMS APPENDIX 

1 . A method of using a router to cache inquiry data corresponding to a target device in a 
network having a plurality of client devices, the method comprising: 

storing inquiry data corresponding to a target device in a cache memory; 
receiving a request for the inquiry data corresponding to the target device; 
reading the inquiry data from the cache memory; and 

providing the inquiry data corresponding to the target device in response to the request. 

2. The method of claim 1 , further comprising collecting the inquiry data corresponding to 
the target device prior to storing the inquiry data corresponding to the target device. 

3. The method of claim 2, wherein collecting the inquiry data corresponding to the target 
device comprises detecting the inquiry data corresponding to the target device as the inquiry 
data corresponding to the target device is transmitted from the target device to a requesting 
host device. 

4. The method of claim 2, wherein collecting the inquiry data corresponding to the target 
device comprises detecting a request for the inquiry data corresponding to the target device as 
the request is routed from a host to the target device and copying the inquiry data 
corresponding to the target device which is returned by the target device in response to the 
request. 

5. The method of claim 1, wherein providing the inquiry data corresponding to the target 
device in response to the request comprises determining whether the target device is busy, and 
providing the stored inquiry data corresponding to the target device if the target device is busy 
and providing inquiry data returned by the target device if the target device is not busy. 

6. The method of claim 5, wherein if the target device is not busy, the inquiry data that is 
returned by the target device in response to the request is stored in the cache memory in place 
of previously stored inquiry data. 
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7. The method of claim 1 , wherein the inquiry data from the cache memory is provided to 
the target device in response to the request regardless of whether or not the target device is 
busy. 

8. The method of claim 1 , further comprising storing inquiry data corresponding to each of 
a plurality of target devices, receiving requests for the inquiry data corresponding to one or more 
of the target devices, determining whether the corresponding target devices are busy and, for 
each of the target devices that is busy, returning the corresponding stored inquiry data, and, for 
each of the target devices that is not busy, returning the corresponding inquiry data returned by 
the target device. 

9. The method of claim 1 , further comprising: upon receiving a first request for inquiry data, 
forwarding the first request to the target device regardless of whether or not the target device is 
busy, storing inquiry data returned in response to the first request, forwarding inquiry data 
returned in response to the first request to a requesting device and, in response to subsequent 
requests, reading the inquiry data returned in response to the first request from the cache 
memory and providing the inquiry data returned in response to the first request in response to 
the subsequent requests. 

10. The method of claim 1 , further comprising determining whether a received command 
comprises a request for inquiry data and: if the received command comprises a request for 
inquiry data, reading the inquiry data from the cache memory and providing the inquiry data 
corresponding to the target device in response to the request; and if the received command 
does not comprise a request for inquiry data, forwarding the command to the target device for 
execution. 

11. A device comprising: 

a router configured to route data between one or more hosts and one or more target 

devices; and 
a cache memory coupled to the router; 

wherein the router is configured to store inquiry data received from the one or more 
target devices and to provide at least a portion of the stored inquiry data in response 
to a request for inquiry data corresponding to one of the target devices that is busy. 
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12. The device of claim 1 1 , wherein the router is configured to detect the inquiry data as the 
inquiry data is transmitted from the target device to a requesting host device. 

1 3. The device of claim 1 1 , wherein the router is configured to detect a request for the 
inquiry data as the request is routed from a host to the target device and copying the inquiry 
data which is returned by the target device in response to the request. 

14. The device of claim 1 1 , wherein the router is configured to determining whether the 
target device is busy, and provide the stored inquiry data if the target device is busy and 
providing inquiry data returned by the target device if the target device is not busy. 

1 5. The device of claim 14, wherein, if the target device is not busy, the router is configured 
to store the inquiry data returned by the target device in response to the request in the cache 
memory in place of previously stored inquiry data. 

16. The device of claim 1 1 , wherein the router is configured to provide the inquiry data from 
the cache memory to the target device in response to the request regardless of whether or not 
the target device is busy. 

1 7. The device of claim 1 1 , wherein the router is configured to store inquiry data 
corresponding to each of a plurality of target devices, to receive requests for the inquiry data 
corresponding to one or more of the target devices, to determine whether the corresponding 
target devices are busy and to return the corresponding stored inquiry data for each of the 
target devices that is busy, and returning the corresponding inquiry data returned by the target 
device for each of the target devices that is not busy. 

1 8. The device of claim 1 1 , wherein if the inquiry data is not stored in the cache, the router is 
configured to: upon receiving a first request for inquiry data, forward the first request to the 
target device regardless of whether or not the target device is busy; store inquiry data returned 
in response to the first request; forward inquiry data returned in response to the first request to a 
requesting device; and, in response to subsequent requests, reading the inquiry data returned in 
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response to the first request from the cache and providing the inquiry data returned in response 
to the first request in response to the subsequent requests. 

19. The device of claim 1 1 , wherein the router is configured to determine whether a received 
command comprises a request for inquiry data and wherein the router is configured to: if the 
received command comprises a request for inquiry data, read the inquiry data from the memory 
and provide the inquiry data corresponding to the target device in response to the request; and 
if the received command does not comprise a request for inquiry data, forward the command to 
the target device for execution. 

20. Withdrawn 

21. Withdrawn 

22. A computer readable medium, wherein the computer readable medium contains one or 
more instructions which are configured to cause a computer to perform the method of using a 
router to cache inquiry data corresponding to a target device in a network having a plurality of 
client devices, the method.comprising: 

storing inquiry data corresponding to a target device in a cache memory; 
receiving a request for the inquiry data corresponding to the target device; 
reading the inquiry data from the cache memory; and 

providing the inquiry data corresponding to the target device in response to the request. 
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IX. EVIDENCE APPENDIX 

Appellants believe that no additional evidence is to be presented. 
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X. RELATED PROCEEDINGS APPENDIX 

Appellants believe that there are no related appeals or interferences. 
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